A Netqueue feature in a hypervisor provides different algorithms to effectively utilize physical network interface card (NIC)'s receive (Rx) queues. Physical MC provides Rx queue features such as receive side scaling (RSS), large receive offload (LRO), latency-sensitive, and Netqueue encapsulates these queue capabilities and makes best attempt to distribute Rx-filters of the clients such as virtual NIC and VM kernel NIC on these Rx queues, activating only required number of Rx queues with required queue feature. In turn, physical NIC tries to match incoming packet against applied Rx-filters. Further processing of that packet is done at the central processing unit (CPU) associated with corresponding Rx-queue. Thus, processing is scaled to multiple CPUs. Netqueue algorithms are based on load calculation. They calculate the load of the filters (based on its transmit (Tx), Rx packet rate), and assign them a Rx queue.
Rx queues are of two types. For the first type, a driver exposes a single Rx queue to a networking stack of a hypervisor. The Rx queue is mapped to single hardware Rx queue, and it accepts Rx-filters (such as MAC based filters or combination of outer, inner MAC). If the incoming packets matches any of those applied filters, then further packet processing is done on that Rx queue. Netqueue layer present in a hypervisor could allocate such Rx queues with additional features like LRO and latency sensitive. Another type is where a driver exposes a single Rx queue with Receive Side Scaling (RSS) feature, which is backed by multiple hardware queues. This pool of queues backing up the single Rx queue with a RSS feature is referred to as RSS engine or RSS pool. Netqueue layer in a hypervisor allocates such Rx queue with RSS feature and applies filter on them. If the incoming packets matches any of those applied filters, then one more level of queue-selection is done. This selection process is done by executing RSS hash algorithm supported by the hardware (such as Toeplitz hash function) on selected fields of the packet. Output of this function is a hash-value that is used as selection criterion to decide the hardware queue in the pool to process this packet. Some devices further provide indirection table that is mapped with different queues for different hash values. Hardware will execute the packet with particular hash value on the queue mentioned in the table.
Currently, physical NICs expose a single RSS queue to a pool of hardware queues (number of hardware queues typically ranges from 8-16). Filters belonging to VM kernel NICs (management or infrastructure traffic) are applied to this RSS queue. But, sharing one single RSS pool for all different traffic can cause problems. For example, a live migration traffic (such as vMotion traffic) may be asynchronous, and thus impose momentary queue-resource constraints on other shared workloads such as virtual storage area network (vSAN) or VTEP (virtual extensible LAN tunnel end point) traffics. That may impede the efficiency of handling the data flows and the RSS queues. Also, RSS hash algorithm typically considers 5 tuple fields of the packet. It could be possible that different shared workloads could have same RSS hash value for their flows and end up sharing same hardware queue. In another example, some traffics such as live migration require high throughput, thus needing multiple Rx queues in the RSS pool for a brief period. In contrast, some other infrastructure traffics have deterministic constant load.